chore: deduplicate the release changelog automatically - #210

This was on #208 but did not make the squash — it was pushed after the merge.
It is needed before #209 is merged, or 5.1.0-beta ships with a changelog
listing 11 changes twice.

The problem

release-please lists the same change twice whenever a pull request was merged
with a GitHub merge commit. The merge commit carries the pull request title in
its body:

Merge pull request #171 from strapi-community/feat/cache-dashboard

feat: add a cache statistics endpoint for the admin dashboard

release-please parses every conventional commit it finds in a message, so
that body line becomes an entry attributed to the merge commit — while the
commit on the branch underneath produces an identical one.

Why it has to be automated

There is no setting for it:

• BEGIN_COMMIT_OVERRIDE is keyed on the pull request, and both commits are
  associated with the same one, so an override would suppress the real entry too.
• changelog-type: github deduplicates by listing pull requests instead of
  commits, but discards the conventional-commit sections entirely.

And it cannot be fixed by hand once: release-please force-updates both the
release branch and the draft notes on every run, so a manual edit is overwritten
the next time anything lands on main.

What it does

Runs after release-please, on every release, over both surfaces — they are
generated separately, so fixing one does not fix the other:

1. CHANGELOG.md on the rolling release branch (commits and pushes only if changed)
2. Every draft release's notes — what a maintainer reads before pressing Publish

Matching strips the trailing ([sha](url)), since the copies differ only by
sha. First occurrence wins, so ordering is unchanged. A heading resets the
comparison, so an entry that legitimately appears under two sections survives.

Verified

Against the changelog currently in #209:

removed 11 duplicate entries
entries: 73 -> 62

and against the old three-package notes from the closed #200: 54 → 35, 19
removed. A second run on either reports no duplicates found, so it is
idempotent and a no-op on future releases now that pull requests are squashed.

Caveat

Only the script is tested. The branch-checkout and gh release edit wiring gets
its first real run when this merges. It runs after release-please, so if it
fails the worst case is the duplicates remaining — it cannot corrupt a release.

Touches a workflow, so it needs a maintainer to merge.

🤖 Generated with Claude Code